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Verfahren zur Vergebiihrung eines Dienstes in einem Kommunika- 
tionsnetz 

Problemstellung der Erfindung 

5 

In einem paketorientierten Koinmunikationsnetz mit Dienstan- 
wendern (z,B. SIP-Clients) , Diensterbringern (z.B, Applikati- 
ons--Servern) und einem vermittelnden Applikationsbroker (z.B. 
SIP Proxy) , der fur die Dauer der Servicebeziehimg zwischen 

10 einem Client und einem Application Server nicht in diese Be- 
ziehung eingebunden ist, (d.h. z.B. kein Stateful SIP-Proxy) , 
ist es fur den Proxy unmoglich eine zuverlassige Vergebiih- 
rungsfunktion fiir registrierte Kunden (Anwender und 
Diensteanbieter) bereitzustellen. Aus Griinden der Effizienz 

15 (Hardware- und Betriebskosten) , ist es fiir grofie Netzkonf igu- 
rationen mit einer Vielzahl von Proxies von Vorteil, wenn ei- 
ne Vergebiihrungseinheit mit mehreren Proxies im Netz gleich- 
zeitig zusainmenarbeiten kann. 

20 

Bisherige Losungen der Problemstellung 

- Proxy bleibt in der Kommunikationsbeziehung fiir die Dauer 
der Servicebeziehung (Stateful Proxy) ^ oder 

25 

Vergebiihrung ISuft separat zwischen Application Server und Client 
ohne Einbeziehung des Proxies r d.h. der Betreiber des Proxies ist 
ausschlieiilich Access-Provider. Eine • Gesamtrechnung aus einer Hand 
auch fiir in Anspruch genommene Dienste las sen sich — wenn iiberhaupt — 
• 30 dann nur mit groBem Aufwand im Postprocessing erreichen Verteilte 

Billingfunktionen beim Proxy-Betreiber und beim Application Server 
Provider; 

Krfordert (a) Sicherstellung, daB der Nutzer eines Services auch 
gleichzeitig Kunde von Proxy- und Serverbetreiber ist, und (b) Uber- 
35 mittlung von Daten an den zentralen Rechnungs er s teller . 
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Losung der Problemstellung gemafi der Erfindung 

Die Erfindung beschreibt ein Verfahren, wie in einera derarti- 
gen Scenario itiit Client, Proxy (=Applikationsbroker, Applika- 
5 tionsvermittlungseinrichtung) , Vergebiihrungseinheit (Billing 
Server) und Applikat ions server eine fur alle Partner zuver- 
lassige Vergebiihrung erreicht werden kann, die zudem fiir den 
Anbieter (Provider) des Grunddienstes (Betreiber der Proxies 
und des Billing Server) einen Mehrwertdienst darstellt. Die- 

10 ser Provider ist damit in der Lage,- seineiii Endkunden eine zu- 
verlassige Rechnung aus einer Hand mit paketorientierten 
Diensten von unterschiedlichsten Partner-Serviceprovidern an- 
zubieten. Dabei kann der Grunddienstanbieter sowohl als ein- 
facher Vermittler eines Dienstes, als auch als Zwischenhand- 

15 ler mit ^^Rebranding" auftreten (Unter ^^Rebranding" wird hier- 
bei verstanden, dass der Betreiber des Proxy einen Dienst ei- 
nes Partner-Serviceprovider nicht unter dem urspriinglichen 
Namen des Dienstes sondern unter einem eigenen Produktnamen 
anbietet) . 

20 

Letztendlich ist der Zweck dieses Verfahren, 

a) Registrierten Endkunden (Clients) mit einem Guthabenkon- 
to in Echtzeit Nutzungsgebuhren fiir angeforderte und ge- 
nutzte Dienste zu verrechnen, oder 

25 b) Registrierten Endkunden regelmafiig (z.B. monatlich) eine 

einheitliche Gesamtrechnung fiir alle genutzten Services 
von unterschiedlichen Providern zu erstellen. 

Mit dem Verfahren wird sichergestellt, dass 
30 a) der Kunde nur das bezahlt, was er nutzt, und 

b) der Diensterbringer fiir seine Leistungen bezahlt wird, 

Daneben schafft dieses Verfahren die Voraussetzung dafur, 
dass dem Kunden als Option schon wahrend der Dienstenutzung 
35 in Realzeit angezeigt werden kann, welche Gebtihren fur den 
Dienst aufgelaufen sind, bzw. bei Prepaid-Service, wieviel 
Guthaben noch vorhanden ist. 
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Grundlage dieser Losung ist eine zuverlassige Vergebiihrungs- 
funktion, in die alle Partner-Komponenten {Client^ Proxy / 
Application Broker^ Application Server) wahrend der Dienste- 
nutzung eingebunden sind. 

5 

Client: Authentifiziert sich bei einem Proxy und fordert 
Dienst an. 

Proxy / Application Broker ; Vermittelt den angeforderten 
Dienst und stolit die Vergebuhrung auf dem Billing Server an. 
10 Billing Server ; Fiihrt Buch iiber die Nutzung dieses Dienstes 
durch den Client . 

Application Server ; Bietet Dienst. an und informiert mit Ti- 
ckets den Proxy iiber Zustandekommen und Verlauf der Service- 
beziehung zwischen ihm und dem Client - 

15 

Die weitere Erlauterung der Erfindung wird durch eine Zeich- 
nung unterstiitzt, die drei Abbildungen lamfasst. 

Abbildung 1 zeigt die Beziehungen der Partner untereinander 
20 und den prinzipiellen Ablauf von der Authentif izierung des 
Clients iiber die Dienstanforderung und Diensterbringung bis 
hin zur Vergebiihrung , Dieser Ablauf wird im folgenden anhand 
von Abbildung 1 beschrieben. 

25 - Nachdem sich der Client mithilfe des Proxy bei dem Authen- 
tif ication-Authorization-Accounting-Server (AAA-Server) 
authentifiziert hat (l)/(2a), informiert der Proxy den 
Billingserver iiber den anstehenden Servicewunsch. Der Bil- 
lingserver verwaltet die Billingtabelle und erzeugt dafiir 

30 auch die Referenzen pi pro Servicewunsch. Diese Referenz 

wird dann an den Proxy zuriickgegeben (2b) . Der Proxy iiber- 
mittelt dann dem Client neben der Angabe, wo sich der Ap- 
plication Server befindet (Destination) und der Billing- 
Reference (pi) auch noch die Adresse des Billingserver s 

35 (3) . Im weiteren Verlauf des Services kommunizieren dann 

Client^ Server und Billingserver unter Ausschlufi des Pro- 
xy. 
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- Der Client fordert mit der Information, die er vom Proxy 
erhalten hat, beim Application Server den gewiinschten 
Dienst an (4) . Dieser bestatigt die Dienstanforderiing an 
den Client (5) . Hiermit ist die Servicebeziehung zwischen 

5 Client und Application Server eingerichtet . 

- Nachdem die Servicebeziehung zwischen Client und Applica- 
tion Server aufgebaut worden ist, und solange der Dienst 
genutzt wird, erstellt der Application Server in regelma- 
fiigen Abstanden Tickets {z.B. 1 pro Minute), die an den 

10 Billing Server gesendet werden (6) . Diese Tickets enthal- 

ten die Reference pi, die dem Billing Server erlaubt, ef- 
fizient auf die Vergebuhrungstabelle (Billing-Tabelle) zu- 
zugreifen, und die Reference si, die der Seorver selbst er- 
stellt hat, und mit welcher er gegebenenf alls spater bei 

15 einer Riickmeldung vom Billing Server effizient auf seine 
Daten zugreifen und eine bestehende Service Relationship 
beenden kann. 

- Nach Erhalt eines Tickets (6) ermittelt der Billing Server 
anhand der in dem Ticket enthaltenen Reference pi den 

20 Client (IP-Adresse CI) und fordert von diesem fiir jedes 

empfangene Ticket eine Bestatigung dieser Vergebiihrungsda- 
ten an (7) . Falls nach einer bestimmten Zeit (z.B. 1 Se- 
kunde) die Bestatigung nicht empfangen wurde, wird die An- 
forderung (7) ein- oder zweimal wiederholt- 

25 - Nach Empfang der Bestatigungsanforderung verifiziert der 
Client das. Ticket und sendet gegebenen falls eine Bestati- 
gung an den Billing Server (8) . 

- Nach Empfang einer Bestatigung vom Client speichert der 
Billing Server das Ticket zu einer spateren Rechnungser- 

30 stellung ab (9) und informiert den Application Server, dafi 
der Client das Ticket bestatigt hat. Im Falle eines Pre- 
paid-Kunden aktualisiert der Billing Server den Guthabens- 
tand des Kunden. 

35 

Sonderfalle bei der beschriebenen Realisierungsvariante der 

Erf indung: 
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- Ptepaid-Kunde : 

Wenn das Guthaben eine bestimmte Schwelle unterschreitet 
informiert der Billing Server den Client, daii das Guthaben 
5 fast aufgebraucht ist. Dies kann z.B. mit der nachsten An- 

forderung einer Bestatigung ftir ein Ticket erfolgen (7) . 
Falls das Guthaben aufgebraucht ist, wird der Billing Ser- 
ver den Eintrag in der Billing Table loschen und weitere 
^ Tickets vom Application Server fiir diesen Kunden nicht 
10 mehr akzeptieren und diese Tickets dem Application Server 

negativ quittieren, woraufhin dieser die Servicebeziehung 
zum Client gegebenenf alls beenden wird. 

Anforderung einer Ticketbestatigung (7) vom Client negativ 
quittiert : 

Der Billing Server informiert den Application Server, da^ 
ein Ticket negativ quittiert wurde, wobei er dem Applica- 
tion Server die Reference si zuruckgibt. Anhand der Refe- 
rence si ist der Server daraufhin in der Lage, die Servi- 
cebeziehung ziam Client zu beenden. 

- Ticketbestatigung vom Client trotz mehrmaliger Anforderung 
nicht erhalten: 

Der Billing Server informiert den Application Server, dsUB 
25 er fur ein Ticket keine Quittung vom Client erhalten konn- 

te, wobei er dem Application Server die Reference si zu- 
ruckgibt. Anhand der Reference si ist der Server daraufhin 
in der Lage, die Servicebeziehung zum Client zu beenden. 

* 

30 - Timer tl fiir Billing Table Eintrag lauft ab. 

Um die Giiltigkeit eines Billig Table Eintrags zu sichern, 
liberwacht der Billing Server den Eingang der Tickets vom 
Application Server. Sobald ein Ticket (6) eintrifft, wird 
der eingestellte Timer zuriickgesetzt . Bei Ablauf des Ti- 

35 mers wird der Eintrag in der Tabelle geloscht. Eventuell 

nachfolgend eintreffende Tickets vom Server werden negativ 
quittiert . 
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Ein. Ausschnitt des Meldungsablaufes (1) - (3) , der in Abbil- 
dung 1 dargestellt und bereits beschrieben ist, ist fiir ver- 
schiedene Realisierungsvarianten der Erfindung in Abbildung 2 
dargestellt - 

5 

Realisierungsvariante 1 : Die in Abbildung 1 beschriebene Va- 
riante . 

Realisierungsvariante 2 : Die Variante 2 unterscheidet sich 
10 von der Variante 1 insofern, dafi der Proxy^ nachdera der Bil- 
ling Server von dem Verbindungswunsch informiert wurde, keine 
Billing Reference (pi) mehr vora Proxy erwartet, sondern die 
Antwort auf den Service Request vom Client ohne pi an den 
Client zuriicksendet (3a) . Der Client erwartet stattdessen die 
15 Billing Reference vom Billing Server und wendet sich mit dem 
Service Request (4) an den Application Server erst dann^ wenn 
er die Billing Reference in einer separaten Nachricht (3b) 
erhalten hat. 

Die Korrelation der Information in den Nachrichten 3a) und 
20 3b) mit dem ursprianglichen Service Request (1) erfolgen iiber 
eine exist ierende eindeutige Reference (Call id^ Tag) , die 
vom Client fiir jeden Service Request generiert wird und in 
den Nachrichten 2b), 3a) und 3b) enthalten ist. 

25 Realisierungsvariante 3 ; Die Variante 3 unterscheidet sich 
von der Variante 2 insofern, dafi der Proxy in diesem Fall 
selbst keine Antwort auf den urspriinglichen Service Request 
(1) an den Client sendet. Nachdem der Billing Server vora Pro- 
xy mit alien relevanten Daten versorgt wurde (2b) , generiert 

30 der Billing Server eine Billing Reference pi und sendet sie 
gemeinsam mit den Daten, die er vom Proxy erhalten hat, als 
Antwort auf den Service Request (1) an den Client - 

35 

Abbildung 3 beschreibt die Einbindung des Billing Servers in 
das Kommunikationsnetz als Partner von mehreren Proxies. Sie 
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zeigt eine prinzipielle Anordnung von Clients, Application 
Servers, Proxies und einem zentralen Billing Server. 

Indem die Billingserver gegebenenfalls mit interner Redundanz 
5 ausgestattet werden und zusatzlich mehrere Billingserver 

gleichzeitig eingesetzt werden konnen, wird diese Realisie- 
rungsvariante hoch verfiigbar und gleichzeitig hoch skalierbar 
(m Billingserver fur n Proxies und z Application Server, m < 
n). 

10 

Berne rkungen : 



- Zu beachten ist, dali dieses Verfahren nicht erfordert, 
dass Server und/oder Client sich bei Beendigung der Servi- 

15 cebeziehung beiiu Billing Server abmelden. So erfolgt auch 

die Versendung eines Vergebiihrungstickets an den Client 
immer im Voraus fiir das aktuelle Vergebiihrungsintervall. 
Damit ist sichergestellt, dass der Client nicht kosten- 
pflichtige Dienste in Anspruch nimmt, ohne dass er dafiir 

20 bezahlt, indem er vor Ablauf eines Vergebuhrungsintervalls 
einfach den Dienst abbricht, um zu verhindern, dass er fiir 
das vergangene Intervall vergebiihrt wird- 

- Der Uberwachungs timer tl in der Billing Table muss auf je- 
den Fall grower als die Lange des Vergebiihrungsintervall 

25 sein, das zwischen Client und Application Server verein- 

bart wird- Es muss grofi genug gewahlt werden, um zu Ver- 
mel den, dass eine verier en gegangene (und deshalb vom Ap- 
plication Server wiederholte) Ticketnachricht an den Bil- 
ling Server dazu fiihrt, dass dieser den Billing Table Ein- 

30 trag fiir ungiiltig erklart. Gleichzeitig darf tl aber nicht 
zu groB gewahlt werden, um zu vermeiden, dass beispiels- 
weise Denial-of-Service Attacken von boswilligen Clients 
zu einer Verknappung der Billing Table Resourcen und 
letztlich zu einer Nichtverfiigbarkeit dieser Dienste 

35 fUhrt, Ein verniinf tiger Wert fiir tl ist 2-3 Mai die LSnge 

des Vergebiihrungs intervall s - Da die Lange der Vergebiih- 
rungsintervalle der einzelnen Servicebeziehungen (siehe 



7 



wo 2005/062265 PCT/EP2004/053227 



Abb. 1) unterschiedlich sein konnen, wird die Lange des 
Uberwachungstimer tl variabel gestaltet. Sobald der Bil- 
ling Server ein Ticket vom Application Server erhalt, ver- 
wendet er die darin angegebene Lange des Ver gebiihrungs in- 
5 tervall und bestimmt daraus die Lange von tl, vim den Emp- 
fang des nachsten Tickets vom Application Server fiir diese 
Servicebeziehung zu uberwachen. Bis zum Empfang des ersten 
Tickets vom Application Server wird ein fur die Billing 
Table einheitlicher fester Initialwert fiir diesen Timer 
10 verwendet (z.B. 5 Sekunden) - 

- Mogliche vertrauensbildende Mafinahmen zwischen Client und 
Application Searver: Die Konditionen fiir die Servicebezie- 
hung (Lange und Kosten des 1. Intervals, Lange und Kosten 
der Folgeintervalle) werden zwischen Client und Server 

15 vereinbart. Durch die Wahl eines kurzen !• Intervalls und 
■ ggf - Sonderkonditionen dafiir kann sichergestellt werden, 

dali auch im Falle einer Nichterbringung der Leistung (z.B. 

Serverausfall, ttberlast, SW-Fehler, Inkompatibilitat von 

Client und Serversoftware) trotz aufgebauter Servicebezie- 
20 hung fiir den Dienstanwender kein oder hur ein geringer 

Nachteil entsteht 

- Bei Ausfall des Billing Servers kann der Application Ser- 
ver aufgrund der ausbleibenden Quittung auf das Ticket die 
Servicebeziehung zum Client gegebenen falls abbrechen. 

25 - Bei Ausfall des Clients wird das Gebiahrenkonto des Kunden 
nicht falschlicherweise welter vom Billing Server be- 
lastet, da Client nicht mehr in der Lage ist, weitere Ti- 
cketbestatigungsanforderungen des Billing Servers zu quit- 

4 

tieren (siehe Sender falle) - 

30 

- Funktionalitat beim Client erweiterbar z.B. um 

i. Kumulierung der vom Billing Server iibermittelten Gebiih- 
rennachrichten und Anzeige dieser Gebiihren am Terminal 
zur Gebiihreniiberwachung in Realzeit. 
35 ii. Moglichkeit fiir Endbenutzer als Option Tickets manuell 

zuriickzuweisen, z.B. bei Erreichen eines bestimmten 
selbstgesetzten Gebiihrenlimits . 

8 
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Zusammenfassend kann folgendes gesagt werden. Das beschriebe- 
ne Verfahren erlaubt dem Betreiber eines Stateless Proxy bzw. 
Application Brokers auf einfache Art und Weise mittels eines 
Billing Servers registrierten Application Service Anbietern 
5 und registrierten Kunden eine zuverlassige, in definierbaren 
Intervallen genaue und vertrauenswiirdige Vergebiihrungsfunkti- 
on anzubieten, indem sich wahrend der Diensterbringung Client 
und Server standig im Hintergrund in regelmaBigen Abstanden 
liber einen unabhangigen Dritten (Billing Server) iiber die da- 
10 flir anfallenden Gebuhren verstandigen und die Vergebiihrungs- 
funktion auch von dem unabhangigen Dritten erbracht wird, wo- 
bei die Vergebtihrungsfunktion auf dem Billing Server insbe- 
sondere fiir mehrere Proxies gleichzeitig erbracht werden 
kann . 

15 

Anwendungsbeispiele 

- Auskunftsdienste 

- Videodienste 

20 - Telefonzusatzdienste/ wie z-B. Konferenzen iiber Konferenz- 
server 

- Mailboxabfragen 

- anonymes Billing fiir Gateways, die aus dem offenen Internet 
cingesteuert werden 
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Patentanspriiche 

1. Billingeinrichtung in einem Kornmunikationsnetz, die 

a) eine von einem Client initiierte Dienstanforderung von ei- 
5 ner Dienstvermittlungseinrichtung empfangt, 

b) ftir den Client beziiglich der Dienstanforderung eine Bil- 
ling-Reference erzeugtf die der Client in einer nachfol- 
genden Dienstanforderung gegeniiber einem Application Ser- 
ver angeben muB/ 

10 c) von dem genannten Application Server erstellte Vergebiih- 
rung-Tickets empfangt;. wobei die Tickets' Inf ormationen 
hinsichtich der vor bzw. wahrend der Dienstnutzung fiir ei- 
nen Dienstnutzer fallig werdenden Gebiihren enthalten, 

d) bezuglich eines vom Application Server empfangenen Tickets 
15 jeweils eine Bestatigungsanfrage an den Client des Dienst- 

nutzers richtet^ 

e) fiir das Ticket eine Gebiihrenregistrierungsaktion durch- 
fiihrtf falls sie von dem Client eine Bestatigung fiir das 
genannte Ticket empfangt. 

20 

2. Billingeinrichtung nach Anspruch 1, 
dadurch gekennzeichnet^ 

dass sie die genannte Billing-Reference an die genannte 
Dienstvermittlungseinrichtung sendet, die die Information 
25 dann dem Client mitteilt. 

3. Billingeinrichtung nach Anspruch 1, 
dadurch gekennzeichnet^ 

dass sie die fiir einen Client erzeugte Billing-Reference dem 
30 Client direkt zusendet. 

* 

4. Billingeinrichtung nach einem der Anspruche 1 bis 3^ 
dadurch gekennzeichnet^ 

dass die genannte Gebiihrenregistrierungsaktion fiir einen Pre- 
35 paid-Client und einen Rechnungs -Client gleichermafien durch- 
f iihrt . 
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5. Billingeinrichtung nach einem der Anspriiche 1 bis 4^ 
dadurch gekennzeichnetf 

dass die genannte Gebiihrenregistrierungsaktion darin besteht, 
dass sie das Ticket zu einer spateren Rechungserstellung ab- 
5 speichert. 

6. Billingeinrichtung nach einem der Ansprtiche 1 bis 5, 
dadurch gekennzeichnet, 

dass die genannte Gebiihrenregistrierungsaktion darin besteht,- 
10 dass sie den Guthabenstand oder Gebiihrenstand des Client ak- 
tualisiert . 

7. Billingeinrichtung nach Anspruch 6, 
dadurch gekennzeichnet^ 

15 dass 

sie den Client informiert, falls der Guthabenstand eine be- 
stimmte Schwelle erreicht bzw. unterschreitet^ 
a) sie den Application Server informiert, falls kein ausrei- 
chendes Guthaben mehr vorhanden ist- 



20 



25 



30 



8. Billingeinrichtung nach einem der Anspriiche 1 bis 7 
dadurch gekennzeichnet, 

dass sie dem Client die fiir die Gebiiihrenregistrierungsaktion 
herangezogene Gebiihr mitteilt. 

9. Billingeinrichtung nach einem der Anspriiche 1 bis 8 
dadurch gekennzeichnet, 

dass sie Dienstanforderungen von einer oder mehreren Dienst- 
vermittlungseinrichtungen empfangt und bearbeitet. 



10. Application Server^ der 

a) von einem Client eine Dienstanf order ung empfangt, wobei 
die Dienstanforderung eine Reference auf eine Billingein- 
richtung enthalt, 
35 b) beziiglich des Dienstes Vergebiihrungs-Tickets erstellt und 
diese an die Billingeinrichtung sendet, wenn er den Servi- 
ce-Request annimmt, wobei die Tickets Informationen hin- 
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sichtich der vor bzw. wahrend der Durchfiihrung des Diens- 
tes fur den Client fallig werdenden Gebuhren enthalten, 
c) von der Billingeinrichtung Mitteilungen daruber empfangt^ 
ob die Tickets durch den Client bestatigt werdenr 
5 d) die Durchfuhrung des Dienstes aufrechterhalt^ solange die 
Tickets durch den Client pbsitiv bestatigt werden. 

11. Application Server nach Anspruch 10 , 
dadurch gekennzeichnet^ 
10 dass er die Servicebeziehung zum Client beendet^ wenn er von 
der Billingeinrichtung die Mitteilung empfangt^ dafi der 
Client eine Bestatigungsanfrage bezuglich eines Tickets nega- 
tiv quittiert hat- 

15 12. Application Server nach Anspruch 10, 
dadurch gekennzeichnet, 

dass er die Servicebeziehung zum Client beendet,. wenn er von 
der Billingeinrichtung die Mitteilung empfangt, dafi der 
Client eine Bestatigungsanfrage bzw. mehrere Bestatigungsan- 
20 fragen bezuglich eines Tickets uberhaupt nicht quittiert hat. 

13- Application Server nach Anspruch 10, 
dadurch gekennzeichnet, 

dass er die Servicebeziehung zum Client beendet, wenn er von 
25 der Billingeinrichtung uberhaupt keine Quittung auf das von 
ihm generierte Ticket erhalt. 

14. Application Server nach Anspruch 10, 
dadurch gekennzeichnet, 
30 dass er die Servicebeziehung zum Client beendet, wenn er von 
der Billingeinrichtung im Falle eines Prepaid-Nutzers beziig- 
lich eines Tickets die Mitteilung erhalt, dafi kein ausrei- 
chendes Guthaben mehr vorhanden ist. 

35 15. Client, der 

a) an eine Dienstvermittlungseinrichtung eine Dienstanforde- 

rung stellt. 
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b) nach einer erfolgreichen Authentif izierung der Dienstan- 
■forderung eine Reference auf den angeforderten Dienst eitip- 
f angt , 

c) anhand der genannten Reference eine Servicebeziehung zu 
5 einem Application Server des angeforderten Dienstes auf- 

baut, 

d) von einer Billingeinrichtung Bestatigungsanfragen iiber 
hinsichtlich des Dienstes fallig werdende Gebuhren emp- 
fangt^ 

10 e) die genannten Bestatigungsanfragen gegenuber der Billin- 
geinrichtung verifiziert und beanwortet. 

16- Client nach Anspruch 15^ 
dadurch gekennzeichnet, 
15 dass er die von der Billingeinrichtung mithilfe der Bestati- 
gungsanfragen ubermittelten Gebiihrennachrichten kumuliert und 
diese Gebuhren dera Endnutzer zur Gebiihreniiberwachung in Real- 
zeit anzeigt. 

20 17. Verfahren zur Vergebiihrung eines Dienstes in einem Kommu- 
nikationsnet z / demgemaB 

a) von einem Client an eine Dienstvermittlungseinrichtung ei- 
ne Dienstanforderung gestellt wird^ 

b) daraufhin mithilfe der Dienstvermittlungseinrichtung eine 
25 Authentifizierung des Clients durchgefuhrt wirdf 

c) nach einer erfolgreichen Authentifizierung durch die 
Dienstvermittlungseinrichtung einer Billingeinrichtung die 
Dienstanforderung mitgeteilt wird, 

d) von der Billingeinrichtung fiir die Dienstanforderung eine 
30 Billing-Reference erzeugt wird, 

e) dem Client eine Reference auf die genannte Billing- 
Reference und eine Reference auf die Billingeinrichtung 
mitgeteilt wird^ 

f ) von dem Client anhand der genannten Dienst-Reference eine 
35 Servicebeziehung zu einem Application Server des angefor- 
derten Dienstes aufgebaut wird und dem Application Server 
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die Billing-Reference sowie die Reference auf die Billin- 
geinrichtung mitgeteilt wird, 

g) von dem Application Server Tickets erstellt und an die 
Billingeinrichtung gesendet werden^ wobei die Tickets In- 

5 formationen hinsichtich der vor bzw. wahrend der Dienst- 
nutzung anfallenden Gebiihren enthalten^ 

h) von der Billingeinrichtung beziiglich eines Tickets jeweils 
eine Bestatigungsanfrage an den Client gerichtet wird, 

i) das Ticket von der Billingeinrichtung zu einer Gebuhrenre- 
10 gistrierungsaktion herangezogen wird, falls das Ticket 

bestatigt wird. 

18- Verfahren nach Anspruch 17 r 
dadurch gekennzeichnet, 
15 dass 

a) das Ergebnis der genannten Bestatigungsanfrage von der 
Billingeinrichtung an den Application Server weitergelei- 
tet wirdf 

b) die Durchfuhrung des Dienstes seitens des Application Ser- 
20 vers aufrechterhalten wird, solange die Tickets durch den 

Client positiv bestatigt werden. 



14 



wo 2005/062265 PCT/EP2 004/05322 7 



1/3 



o 



LU 
CO 

O 



CO 

Q 

1 1 I 

CO 




2: 

CD 
CO 



0? 
CO 



Time- 
out 


T^Csi - • . ^ 


Cent 
IP-Addr. 


T-CM . . . C= 

o o o 


Server- 
Ref. 


CO CO • CO 


Bil ing- 
Ref. 


Q. O. • • • Q 



wo 2005/062265 PCT/EP2004/053227 



3/3 



